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[57] ABSTRACT 

A method is described for enabling one or more exter- 
nal processing systems to access service programs of the 
local processing system, the local : processing system 
havmg an operating system kernel and supporting mul- 
tiple protocol stacks and multiple hardware device driv- 
ers. The method begins by generating a master control 
structure for each compatible protocol stack and device 
driver supported in the local processing system. The, 
hardware device drivers are then monitored for receipt, 
from an external processing system, of any requests to 
access the service programs. Upon receipt by a protocol 
stack/device driver pair of an access request for one of 
the service programs, the master control structure is 
cloned into a control structure (DCB) for that service 
program, the resulting service program control struc- 
ture including control information to associate the ser- 
vice program with the protocol stack/device driver 
pair receiving the access request. Then, the method 
creates a virtual circuit representing a communication 
path between the external processing system, the proto- 
col stack/device driver pair receiving the access re- 
quest, and the service prograrn. A control block (NCB) 
is then generated for each predetermined block of ac- 
tual data to be communicated to and from the service 
program. The service program control structure and 
the virtual circuit are maintained while actual data is 
commimicated between the service program, the proto- 
col stack/device driver pair and the external processing 
system. 

17 Claims, 2 Drawing Sheets 
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access service programs of the local processing system 
NfETHOD FOR REMOTELY ACCESSING in a transparent manner. 

SERVICE PROGRAMS OF A LOCAL PROCESSING It is another object of the invention to provide a 
SYSTEM. SUPPORTING MULTIPLE PROTOCOL : method in which a multiuser operating system functions 
STACKS AND MULTIPLE DEVICE DRIVERS 5 as a server providing file, applications and peripheral 

access to and from diverse local area networks such as 
TECHNICAL FIELD Novell Netware, OS/2 LAN Manager. NETBIOS and 

^ , „ ^ ^ TCP/IP-NFS. 

The present mvention relates generally to methods According to the method of the present invention, . 
and systems for mlegratmg djvcnc compu cr systems certain daU control structures are created to enable the 
and more particularly to a method for enabhng one or jocal processing system to identify what service pro- 
more external processmg systems to transparently ac- being accessed in the operating system kernel 

cess service programs of a local processmg system. ^^5^^ dato from that service program needs to be 

BACKGROUND OF THE INVENTION communicated at the hardware level. Multiple different 

IS kinds of servicie programs can thus be multiplexed to 

The UNIX ® System was designed in the I970's as a multiple different kinds of protocols on multiple differ- 
general purpose, multiuser, interactive operating system ©nt kinds of hardware drivers. The result is a "server" 
for minicomputers. The communications environment that is transparent to a network operating system, thus 
in UNIX is designed around a simple character input- functionally a "clone'* of all existing network servers 
/output interface mechanism. This mechanism, which 20 sAich as Banyan. Novell and Lan Manager, 
processes one character at a time, is thus unable to effec- It is yet a further important feature of the invention to 
lively support a broad range of devices, speeds, modes implement the above-identified method using a "dual 
and protocols, such as the cunent generation of net- personality" interface between the service programs 
working protocols exemplified by Systems Network and the protocol stacks and between the protocol stacks 
Architecture (SNA), Transmission Control Protocol- 25 and the hardware level. Each such interface supports 
/Internet Protocol (TCP/IP) and Xerox Network Sys- both STREAMS and Berkeley Sockets calls. This ar- 
tems (XNS). Such protocols provide significant func- chitecture is extremely advanugeous because it enables 
tionality and features but cannot be efficiently inte- service programs written for the BSD environment to 
grated for use with the UNIX operating system due the be compiled and run unmodified in the UNIX environ- 
lack of a standard interface. 30 ment. and vice versa. 

There have been attempts to solve this problem It is still another object of the invention to implement 
through the development of special tools such as connection-oriented service at the device driver level 
AT&T's STREAMS, which is a coUection of system 'o^* « UNIX-based local processing system, 
calls, kernel resources and kernel utility routines that I" preferred embodiment, these and other objects 
dcfme standard interfaces for character input/output 35 of the invention are provided m a method, usmg a loca^ 
within the UNIX kernel, and between the kernel and P'^^^ssmg system havmg an operating system kernel 
the rest of the UNIX System. The STREAMS mecha- and supportmg multiple protocol stacks and multiple 

nism is described in the UNDC System V/386 Release ^tT™L'! iTmOn'J^^^^ 
- - D - /ioQQ\ T-u Ti*.i,-i«, c»..^.*^ T^;* lemal processmg systems to access service programs of 
Stream Pnm^^^^^ ^"Tk « the local processing system. The method comprises the 
nbution ("BSD") form of the TO X kerne hasa snni- generating a master control structure for 
larTuechamsm commonly referrt^ l^^'^^'^^^^^^f each compatible protocol sUck and device driver sup- 
Conceptually. AT&rs STREAMS and Berkeley processing system, the master con- 
Sockets support development of mterfaj^^^^ for structure for each protocol stack/device driver pair 
character mput/output^withm the UNIX kernel, and ^5 including control information to facilitote dau transfer 
between the kernel and the user level. Unfortunately, ^^^^ protocol stack associated with that 
these tools have not been effectively developed to the protocol stack/device driver pair. Thereafter, the hard- 
extent necessary to enable the UNIX operatrag system ^^^^ ^^^-^^^ divers are monitored for receipt, from an 
to be mterconnected and mtcgrated with cxistmg di- external processing system, of any requests to access the 
verse networks. The many desirable features and char- 5^ service programs. Upon receipt by a protocol stack/de- 
acteristics of the UNIX System therefore have not been yjce driver pan- of an access request for one of the ser- 
available to users of PC's and local area networks be- vice programs, the master control structure is cloned 
cause of this connectivity problem. into a control structure (DCS) for that service program. 
It would therefore be desirable to provide a method resulting service program control structure includ- 
of integrating a multiuser, interactive operating system 55 ing control information to associate the service program 
such as UNIX with other computing systems, networks, with the protocol stack/device driver pair receiving the 
applications and information. access request 

BRIEF SUMMARY OF THE INVENTION eirS^Tcp^rgTcSri^f p^^;^^^^^ 
It is an object of the present invention to provide a 60 the external processing system, the protocol stack/de- 
method and system supported on a multiuser operating vice driver pair receiving the access request, and the 
system such as UNIX that is transparently integrated service program. A virtual control block (VCB) is also 
with other diverse computing systems. created for the virtual circuit. The VCB points to or 
It is a more specific object of the present invention to references the relevant hardware interface at which the 
provide a method, using a local processing system hav- 65 access request was received. A control block (NCB) is 
ing ah operating system kernel and supporting multiple then generated for each predetermined block of actual 
protocol stacks and multiple hardware device drivers. data to be communicated to and from the service pro- 
for enabling one or more external processing systems to gram. The control block includes a datia portion and 
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information identifying the service program control 
structure for the service program. Each block or 
**packet" of data points to a DCB, and each DCB refers 
to a VCB for the virtual circuit. The method maintains 
the service program control structure and the virtual 5 
circuit while actual data is communicated between the 
service program, the protocol stack/device driver pair 
and the external processing system. During such data 
conununication, the data portion of each control block 
is transmitted over the virtual circuit. Upon completion 10 
of the data communication, the service program control 
structure and the virtual circuit (and its corresponding 
VCB) arc terminated. 

The method also advantageously implements connec- 
tion-oriented service at the datalink layers. Every data 15 
packet to be transmitted from the local processing sys- 
tem in response to the access request is sent from the 
service program down to the hardware level with just 
an address identifying the original source of the request 
(i.e., the external processing system device). If the ad- 20 
dress does not identify an existing connection, the con- 
nection is still established automatically. If the address 
does identify an existing connection, the connection 
identifier for the existing connection is retrieved and the 
packet is transmitted on that number. A unique hash 25 
algorithm is used to increase the speed at which connec- 
tion identifiers for existing connections are retrieved. 

The foregoing has outlined some of the more perti- 
nent objects of the present invention. These objects 
should be construed to be merely illustrative of some of 30 
the more prominent features and applications of the 
invention. Many other beneficial results can be attained 
by applying the disclosed invention in a different man- 
ner or modifying the invention as will be described. 
Accordingly, other objects and a fuller understanding 35 
of the invention may be had by referring to the follow- 
ing Detailed Description of the preferred embodiment 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present 40 
invention and the advantages thereof, reference should 
be made to the following Detailed Description taken in 
connection with the accompanying drawings in which: 

FIG. 1 is a schematic block diagram of a local pro- 
cessing system supporting multiple protocol stacks and 45 
multiple hardware device drivers according to present 
invention; 

FIG. 2 is a flowchart diagram of a preferred method 
of the present invention for enabling an external pro- 
cessing system to access one of the service programs of 50 
the local processing system of FIG. 1; and 

FIG, 3 is a flowchart diagram of a hash algorithm of 
the present invention for facilitating connection-ori- 
ented service at the hardware level of the local process- 
ing system of FIG. 1; and 55 

FIG. 4 is a schematic block diagram of an alternate 
embodiment of the invention wherein the local process- 
ing system includes common service interfaces for im- 
plementing UNIX and Berkeley Sockets function calls. 

DETAILED DESCRIPTION ^ 

FIG. 1 illustrates the basic architectural design of a 
local processing system 10 incorporating the principles 
of the present invention. Local processing system 10 
includes an operating system kernel 12 and a user space 65 
14 supporting a plurality of service programs 16. Ser- 
vice programs 16 provide various types of user services 
such as file access and print functions. According to the 



4 

invention, the operating system kernel 12 supports mul- 
tiple protocol stacks 18 and multiple hardware device 
drivers 20. In one embodiment of the invention, the 
service programs 16 interface to the protocol stacks 18 
via calls to an interface or "transport" layer 17. Like- 
wise, the protocol stacks 18 interface to the device 
drivers through an interface layer 19. In an alternate 
embodiment of the invention described below in con- 
nection with FIG. 4, the transport layers 17 and 19 
support multiple different types of interfaces (e.g., 
UNIX System V or Berkeley Sockets). 

Although not meant to be limiting, preferably the 
local processing system 10 is a multiuser computer pro- 
cessing system such as a standard 386 or 486 personal 
computer (PC) nmning SCO UNIX, The service pro- 
grams include for example SQL 16a, NETWARE 16^ 
LAN Manager 16c, NFS (Network File System) 16rf, 
and FTAM (OSI) I6e, The protocol stacks 18 include 
for example the protocols: NETBIOS 18fl, XNS IHb, 
TCP/IP 18c and OSI ISd, The hardware device drivers 
interconnect to Ethernet 20a (ISO specification 802.3), 
ArcNet 2Qb (ISO specification 802.4), token ring 20c 
(ISO specification 802.5), Starlan 2Qd and twisted pair 
Ethernet 20e. 

According to the invention, the local processing sys- 
tem 10 includes appropriate software for enabling one 
or more external processing systems 22*7-22^ to access 
the service programs 16 in a transparent manner. The 
software thus provides "interoperability" to the exter- 
nal processing systems 22 by enabling the local process- 
ing system, e.g., a PC running UNIX SCO, to act as a 
server providing file, applications and peripheral access 
to and from the diverse local area networks intercon- 
nected to these systems. By way of example, worksta- 
tion users supported on an external processing system 
22 can gain transparent access to UNIX files, applica- 
tions and facilities from the workstation's native envi- 
ronment. 

Referring now to FIG, 2, a flowchart diagram is 
shown of a preferred embodiment of a method of the 
present invention for enabling the multiple external 
processing systems to transparently access the service 
programs of the local processing system. The method 
begins at step 30 wherein a master control structure is 
first generated for each compatible protocol stack 18 
and device driver supported in the local processing 
system. The master control structure for each protocol 
stack/device driver pair including control information 
to facilitate data transfer to and from the protocol stack 
associated with that protocol stack/device driver pair. 
Thereafter, at step 32, the hardware device drivers are 
monitored for receipt, from an external processing sys- 
tem 22, of any requests to access the service programs 
16. Upon receipt by a protocol stack/device driver pair 
of an access request for one of the service programs, the 
method continues at step 34 by cloning the master con- 
trol structure into a control structure (DCB) for that 
service program. The service program control structure 
that results from step 34 includes control information to 
associate the service program with the protocol 
stack/device driver pair receiving the access request. 

The method then continues at step 36 by creating a 
so-called "virtual circuit" representing a communica- 
tion path between the external processing system 22, the 
protocol stack/device driver pair receiving the access 
request, and the necessary service program 16. At step 
37, a virtual control block (VCB) is created for the 
virtual circuit. A network command block (NCB) is 
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then generated at step 38 for each predetermined block 
of actual data to be communicated to and from the 
service program 16. The KCB includes a data portion 
and information identifying the service program control 
structure (DCB) for the service program. Each packet 
of data sent to or from the service program points to a 
DCB for the service program and each DCB has a 
virtual circuit identification number of "vcid" that re- 
fers to a VCB for the virtual circuit. The VCB itself 
points to the hardware interface. 

Referring back to FIG. 2, the method continues at 
step 40 wherein the service program control structure 
and the virtual circuit constructs are maintained while 
actual data is communicated between the service pro- 
gram, the protocol stack/device driver pair and the 
external processing system. During such data communi- 
cation, the data portion of each control block is trans- 
mitted over the virtual circuit Upon completion of the 
data communication, the service program control struc- 
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-continued 
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tbort nd— req; 


/* TLI req in err •/ 


tborl od—crr; 


/• TLI err to lend up V 


short B<1 migic; 


/• Stnity check V 


short nd_vcid; 


/• vcid lo use liier •/ 


tbon wL-ntmeid; 


/• Ntme number •/ 


. thort bd_pid; 


/• Pid of proceu •/ 
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As noted above, each block of data (e.g., a call, a call 
response, a connect request, a connect response, or 
actual data such as the results of a file copy) transmitted 
to or received by the service program points to a DCB 
having the above-identified data fields. The DCB pro- 
vides the kernel all the information needed to faciliute 
coimections to/from a service program. The informa- 
tion includes a number of identifiers. Referring now to 
the above description, the identifier "pid" is the service 



. _ program identifier. The **nameid" is the index into a 

ture and the virtual circuit (and its corresponding VCB) *0 ^^^^ table. Each computer on the network is given a 
are terminated as Indicated at step 42, 



Therefore, according to the method of the present 
invention, the above-identified control structures are 
created to enable the local processing system to identify 



name. Upon system initiation, the local processing sys- 
tem's name is registered in the table; thereafter, names 
of remote computers are registered as connections are 
established. The identifier "vcid'* is the identifier for the 



what service program is being accessed in the operating .^^ virtual circuit created at step 36 of the method. The 
system kernel and where data to/from that service pro- 
gram needs to be communicated at the hardware level. 
This operation is carried out for each connection that is 
established, i.e., for each access request. Multiple differ- 
ent kinds of service programs can thus be multiplexed to 
multiple different kinds of protocols on multiple differ- 
ent kinds of hardware drivers. The result is a "server" 
that is transparent to a network operating system, thus 
functionally a "clone" of all existing network servers 
such as Banyan, Novell and Lan Manager. In effect, the 
local processing system acts as the interface between 
various different types of networks. With multiple ser- 
vice programs and multiple external processing sys- 
tems, the method facilitates interoperability between 
normally heterogeneous computer systems irregardless 
of the user's current operating environment. 

As suted above, the method generates a service pro- 
gram control structure or DCB that includes control 
information to associate the service program with the 
protocol stack/device driver pair receiving the access 
request. The DCB includes all information that the 
service program will need during the transaction, i.e., 
the tisc of the service program to comply with the ac- 
cess request. The preferred format of the DCB is set 
forth below: 



30 



35 



40 



45 



SO 



DATA COhTTROL BLOCK 



struct NB_dcb 
mblk—t •nd_jnbllt; 
mbllct *od-^t«); 
qucue_t 'nd-j^dq; . 
ttruct nbaddr Dd^tddr; 
. struct nbsddr cd_laddr; 
struct NB— deb *xid_bead; 
struct NB_dcb *nd:.xq; 
char *nd.Jistennct^ 
mbUct *Dd-Jocbp: 
unsigned long nd^optckeu; 
unsigned, long nd ..ipickcts; 

shon nd mucon; 

thon nd leqnum; 

shon nd-:qlen 
short nd-jninordev; 
shon od-jute; 
shon nd_fUg3; 



/• Mblk to be freed •/ 55 

/* d«U before conndone */ 

/• read q to send pkts V 

/* Foreign address •/ 

/• Local address V 

/• Head of queue •/ 

/* Connection queue V 60 

/• Listcn-NCB for cancel •/ 

r kwtl bik ♦/ 

/* Kumber of out packets */ 

/* Number of in packets */ 

/• Maximuni number •/ 

/• Sequence number •/ (i5 

^ Qlen of connections */ 

Minor device uum */ 
/• TLI Slate of dev •/ 
/* Info about dev •/ 



identifier "err" stores any error currently reported that 
can then be sent up to the upper layer; the identifier 
"req" stores errors that occur in the upper layer that are 
sent downward. The "flags" field identifies the type of 
interface. The "state" field identifies the state of the 
interface, e.g., open, closed, data transfer. The identifier 
"minordev" is the actual physical device number con- 
nected to the service program. **Qlen" is the queue 
length identifying the maximum number of outstanding 
connection requests that can be supported at one time. 
The Vseqnum" is the sequence number of the pending 
connections. "Maxcon" is the maximum number of 
simultaneous connections. 

The fields "ipackets" and "opackets" reflect the num- 
ber of in and out packets for use in statistical reporting. 
The identifier "iocbp" refen to the input/output con- 
trol block that the DCB point to. "Listenncb" is the 
pointer to the NCB that is listening. The identifier "cq" 
defines the connection queue, whose head is defmed by 
the "head" identifier. The field "laddr" identifies the 
local network address; "faddr" is the remote network 
address. The identifier **rdq" is the read queue that data 
comes in on. "Dataq" is the data queue where data is 
stored before connection is completed. "Mblk" is the 
actual message block for the communication. 

The VCB is created for each virtual circuit, and is 
found by the **vcid" in the DCB. As discussed above, 
the VCB itself specifically points to the structure refer- 
ring to the hardware. The preferred format of the VCB 
is set forth below: 



VIRTUAL CONTROL BLOCK 



typedef struct vcb 
NAMCB far 'oamcb; 
BYTEman>e[16); 
TIMER wdlimer: 
BYTE rpadr[6]: 
NCB far •ctL.ncb; 
WORD tbsendp; 



/• ptr to name table entry •/ 
/• remote name V 
/* wstchdog timer */ 
/* addrett at other end */ 
/* calls and hangups */ 
/* 0: no loopback'd send 

pending */ 
/* 1: loopbsck . send pending 

but V 
/* delaying because no 

recvr •/ 
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-continued 



VIRTUAL CONTROL BLOCK 



NCB far •rv_ncbhcad; 
TIMER rv_timer; 
WORD rv— alrcady-uscd; 

WORD rv^bafused; 

NCB far *siu_ncbhead; 
TIMER m—tiffler; 

WORD w, .nmt; 
V 

WORD sn Bckcd; 

BYTE vdd; 
BYTE state; 

BYTE flags 

BYTE nanicid; 
BYTE hangupsis; 

BYTE wdcount; 



BYTE no; 

BYTE sto; 
BYTE rvcid; 
BYTE rv_seq; 

BYTE sn_timc; 



BYTE sn_seq; 
struct NB_ifnct» 



/• pending receives •/ 
/• receive timer •/ 
/* bytes used in next recv 
msg •/ 

/• bytes already rcvd into rv 

neb V 
/* pending sends V 
/* send timer ** also used for 

call resp 
/* bytes last sent for sn neb 

/* bytes sent and acked for sn 
neb V 

/* circtut id that user sees 
/• VSTATEfree.calLhangup. 

active*hpen(i •/ 
/• flag bits.VFLAGcaller and 

loopback •/ 
/* index to name table */ 
/* hangup sts when state k 

hpend V 
/' dccrcrocnicd when wdtimer 

expires •/ 
/* reloaded when packet 

received •/ 
/• receive timeout, & sec 

incR •/ 

/• 3end timoui, \ sec incs •/ 
/♦ vcid that remote end uses •/ 
/• recv expected seq # - 0 or 

0x10 V 
/* total time elapsed attempting 

send V 
/• also used for call retry 

counter •* ♦ 
/• sendseq tf - 0 or Ox 10 V 
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ing connection. The "nameid" is the index to the name 

table. The byte "hangupsts" determines if there is a 

hangup pending. The byte "wdcount" represents the 

count that is started by the 'Vdtimer", The "rto" and 
5 "sto" bytes are the timeout parameters. 

The "rvdd" field identifies the "vcid" of the remote 
processing system. When packets are transmitted or 
received, each packet is sequenced (with a "0" or *'!") 
so that the sequence of the packets can be verified. The 
10 byte "rv«scq" is the sequence bit of a received packet; 
likewise, "sn.-seq'* is the sequence bit for a transmitted 
packet The "sn— time" field is a count of the total 
elapsed time waiting for an acknowledgement for a 
transniitted packet. Finally, the "NB ifnet" pointer 
15 points to the specific hardware device coimected. 

Each remote processing system has at least one de- 
vice driver and protocol stack. The remote system gen- 
erates the network command blocks and virtual control 
blocks as required to facilitate the transmission. 
20 As discussed above, each data packet delivered to or 
from the service program is associated with an NCB. 
The preferred format for this structure is set forth be- 
low: 
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NETWORK COMMAND BLOCK 



The pointer "namcb" points to a name control block 
identifying the name of the local processing system. 
Byte "mame" is the name of the remote machine that 
the local processing system is communicating with. 
Each virtual circuit has a timer associated therewith; 
the "wdtimer" is a watchdog timer which is restaned 40 
with each new packet. If the time times out, the virtual 
circuit is terminated. The byte "rpadr" is the network 
address of the remote computer. The "ctl_ncb" is a 
control network command block established for the 
virtual circuit to monitor calls and hangups. The 45 
"Ibsendp" field is a flag indicating whether or not the 
virtual circuit defines a loopback within the local pro- 
cessing system (for testing purposes) or an external 
connection. The pointer "rv-jicbhead" is a pointer to a 
head of a linked list of NCB's posted to receive incom- 
ing data packets. Likewise, the pointer **sn_ncbhead" 
points to the head of a linked list of pending NCB's 
waiting to be sent. 

When a message is lengthy, it must be fragmented and 
thus the system needs to keep track of data blocks so 
that the data can be properly reassembled later. The 
"rv—timer" starts when a dau block of a fragmented 
message is received. The "sn timer" starts upon trans- 
mission of a data block; if an acknowledgement is not 
received before it times out, the data block is resent. 
The "sn— sent" and "sn— acked" fields indicate the num- 
ber of bytes sent and how many of such bytes were 
acknowledged, respectively. The byte "vcid" is the 
circuit identifier that the user sees. The byte "state" 
identifies the state of the virtual circuit, namely: free, 
call, hangup, active or hangup pending. The "flags" 
field includes the bit flags indicating whether the virtual 
circuit is in a loopback or test mode or reflects an outgo- 



typcdef struc neb 
BYTE cmd; 
BYTE err; 
BYTE vcid; 
30 BYTEnamcnum; 
char 'bufptr; 
short buflcn, 

BYTE mamctNBNAMSZ]; 
BYTE lname[NBNAMSZ]; 
BYTE rto; 
35 BYTE sto; 

void (•aniptr) ( ); 
unsigned char lana; 
un&igned char done; 
struct neb far •next; 
struct neb far •canncb; 
/• 
V 

short fromdoncb; 
mblt_t "mblk; 
mblk_t 'dblk; 
struct NB_dcb •deb; 



/♦ command code •/ 

/• error return •/ 

/• session id •/ 

/• name number •/ 

/■ buffer address •/ 

/• buffer length */ 

/• remote name •/ 

/• local name •/ 

/■ receive timeout •/ 

/• send timeout •/ 

/• anr entry •/ 

/' adapter number •/ 

/• cmd complete when not ff •/ 

/• (•) next on list •/ 

/• (•) cancel neb for this neb •/ 



/• Norcro if from doncb */ 
/• Mblk to free for this •/ 
/• Dau Mbufin this neb •/ 
/• DCB for this NCB •/ 



The upper portion of the NCB (above the last four 
lines) is similar to the network command block struc- 
ture of NETBIOS. For example, the byte "cmd" is a 
one-byte field that contains the command to be exe- 
50 culed. The "err" byte identifies any error code re- 
turned. The "vcid" byte identifies the virtual circuit. 
The identifier "*bufptr" is a four byte field that contains 
a pointer to a buffer. The identifier "buflen" contains 
the number of bytes stored in the buffer pointed to by 
55 the •bufptr field. For receive commands, the number is 
the actual number of bytes received; for transmission 
commands, the number is the number of bytes to send. 
The "mame" is the name of the remote machine; the 
"Iname" is the name of the local processing system (and 
60 corresponds to the **nameid" in the DCB). The 
"char— lana" is the card number of the hardware device 
in the local processing system. The flag "char— done" 
represents whether the command is complete or pend- 
ing. The field "neb far *next" identifies the next NCB 
on the linked list to be sent. The structure "neb far 
♦canncb" is used to cancel an NCB. 

The last four identifiers are included to facilitate the 
method of the present invention. The identifier "from- 
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doncK* determines whether a data packet is coming most significant bytes: In this manner, the location of 
from a STREAMS interface. According to the inven- the connection identifier takes place much more rapidly 
tipn, each message may have associated therewith one because many of the cards identified in a connection 
or more data blocks. The field "*mblk" identifies the table will have common MSB's. Once the connection 
message and the field ***dblk** identifies the data blocks S identifier is located, it is retrieved at step M and the 
associated therewith. Most importantly, the "*dcb" packet is transmitted on that number, 
associates the service program control structure or Therefore, it can be seen that the invention provides 
DCB with the NCB. As previously discussed, a DCB is automatic connections as well as automatic lookup of 
established for each service program using the protocol existing connections in the datalink layer. All data 
stack. 10 packet addresses are resolved into a connection identi- 

Of course, each remote processing system has at least f^er based on the hash index O-e., the remainder) and the 
one device driver and protocol stack. The remote sys- backwards indexing routine. This operation faciliuies 
tem generates the network command blocks and virtual "connection-oriented" service at the hardware level, 
control blocks as required to facilitate the transmission. Referring now to FIG. 4, a schematic block diagram 

The above-identified description relates to connectiv- 15 shown of an alternate embodiment of the invention 
ity at the transport and NETBIOS layers. In particular, wherein the local processing system includes common 
the DCB and its related constructs facilitate reliable ^rvice interfaces for implementing UNIX and Berkeley 
data transmission, i.c., the scndmg of dau and the ac- Sockets function calls. By way of background, a user 
knowledgement thereof, between the service pro- jg^^j ^^^^^ program must communicate to a kernel 
gram(s) 16, transport interface 17 and protocol stacks 20 j^^j protocol slack via the service level interface layer 
18. Turning now to the hardware level, the present ,7 ^ .^own in FIG. 1. In UNIX System V, the 
invention implements so^alled connection-onented ^^^rfzct is called "TLI" or the transport level intcr- 
service at the datalink layer on a UNIX-based process- ^^^^ htrktlty Standard Distribution (BSD) UNIX, 
mg system. Such service is effected by a unique routine ^^^^^^ ^ Berkeley-style Sockets interface. Ac- 

for relating the multiple coimection identifiers a he 25 ^^^^ ^ ^^^^^ ^ ^^^^^^ ^j. ^^^^ 

tn^x«f4cr\'''A'^' T"^ '^T'^'Z'^ invention, a dual •'personality" interface layer is pro- 

NETBIOS evel. Accord>^^^^^^ th^ mvcntion^^^^ up^ ^ ^^^^ ^^^^^ ^ l^^^ 

levels (i.e ^^^T^^.^ col stacks, and between the prot^ol stacks and the 

have no knowledge of the connection at the hardware . tu... if « -^r^^r.r^ « 

the hardware level with just an addrns identifying the protocol suicks therefore can be used for service 

original source of the request (i.e.. the external prcLss- " ^"""''^ 

ing system device). If the address does not identify an 3$ BSD UNIX or UNIX System V STREAMS. ^ 
eristtag connection, the connection is esublished auto- J^'^^^I^}^ »° f>epreferred architecture is 
maticaJly. If the address does identify an existing con- shown. The upper level dual interface 17 aUows service 
nection, the connection identifier for the existing con- P™*^""™. wc''*t'^1°'°^' both Sock- 

nection is retrieved and the packet is transmitted on that f » "<1 ,V **. low"„>e^«' 

40 interface 19 has the ability to ttlk to two different types 

A unique hash algorithm is used to increase indexing «»/ drivers, Sockets-type and STREAM S-type drivers, 
speed to determine the comiection identifiers for exist- 1/ *e local processmg system is a BSD machine, the 
iigcomiections. Referring now to the Howchart of <»"1 ^^f'^'^}^ f^^SV^^ t'**'' v."*^" 
FIG. 3. this routine is now described. At the outset, the ware caUs. If the system is a WIX System V machme, 
local processing system has associated therewith a plu- 45 theinterface 19 generates STOEAMS-type calls, 
rality of "connection tables" each of which includes a . The upper layer-dual wterface 17 mcludes a SockeU 
plurality of addresses and connection identifiers. The interface layer 60 and a TLI mterface 62 havmg a plu- 
Ubles are formed automatically as connection requests of mod>^62fl-6M. For example, module 62« is 
come in and as the system connects to other systems; « JHd^ SH^i "^'''w f^^ u " 
i.e., upon esublishment of connections. The routine JO NETBIOS STREAMS module, and so forth for other 
begins at step 50 upon receipt of each data packet in- modules normally compnsing a TLI mterface on a 
eluding the routing address. At step 52. a test is made to UNIX System V machine. The Sockets mterface layer 
determine if the addnss identifies a known connection. «> includes a switch PROTOSW 64 which functions to 
if not, the connection is established at step 54. If the select the proper module depending on the calls re- 
resuh of the test at step 52 indicates that the address J5 cdved from the service programs. If the calls arc Berke- 
corresponds to an existing connection identifier, the ley iSockets, the Sockets interface layer 60 translates 
routine contiiiues at step 56 by adding together the two those calls into STREAMS-type calls and direcu the 
least sipiiricant bytes (LSB's) of the address. At step 58, calls, via the switch 64, to the appropriate module 62. If 
the result of the addition step 56 is then modulo-divided the calls from the service programs are in STREAMS, 
by a prime number equal to the number of connection » they are sent directly to the modules 62 without change. 
Ubles. The remainder generated from the modulus divi- Likewise, the lower level dual interface layer 19 in- 
sion is then used at step 60 as the index to one of the eludes an Ifhet/STREAMS interface 68 and a 
connection tables Specifically, the remainder identifies . STREAMS driver 70. Because BSD drivers generally 
the particular connection table. •• deal with devices directly, the Ifnet/STREAMS inter- 
Thereafter, at step 62, the routine indexes into the 63 face can talk directly to the drivers interfacing, for 
particular connection table ' (corresponding to the re- example, to Ethernet and X.25. The STREAMS driver 
mainder) in a "backwards" manner, i.e., by using the 70, however, is. "virtual" in that it looks like a direct 
least si^iificant bytes of the address rather than the hardware driver but really is a software driver. The 
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output of the driver 70 is one or more Berkeley style 
hardware device drivers. 

The networking interfaces described above provide 
significant advantages. Most importantly, service pro- 
grams written for the BSD environment can be com- S 
piled and run unmodified on a UNIX System V ma- 
chine. Programs written for the TLI environment can 
be run unmodified because of the TLI interface. Be- 
cause Berkeley Sockets is supported in the kernel, no 
kernel sources are modified. At the hardware level, the 
Ifnet layer has an extra driver for multiplexing to 
STREAMS drivers. Both Berkeley-style Ifnet drivers 
that talk directly to hardware as well as Ifnet drivers 
that talk to STREAMS are provided. Therefore, differ- 
ent network applications can access multiple protocols 
through a common dual personality interface support- 
ing both BSD Sockets and AT&T UNIX System V 
STREAMS calls. 

It should be appreciated by those skilled in the art 
that the specific embodiments disclosed above may be 
readily utilized as a basis for modifying or designing 
other structures for carrying out the same purposes of 
the present invention. It should also be realized by those 
skilled in the art that such equivalent constructions do 
not depart from the spirit and scope of the invention as 
set forth in the appended claims. 

I claim: 

1. A method, using a local processing system having 
an operating system kernel and supporting multiple 
protocol stacks and multiple hardware device drivers, 
for enabling one or more external processmg systems to 
access service programs of the local processing system, 
comprising the steps of: 

(a) generating a master control structure for each 35 
compatible protocol stack and device driver sup- 
ported in the local processing system, the master 
control structure for each protocol stack/device 
driver pair including control information to facili- 
tate data transfer to and from the protocol stack 40 
associated with that protocol stack/device driver 
pair; 

(b) monitoring the hardware device drivers for re- 
ceipt, from an externa! processing system, of any 
requests to access the service programs; 45 

(c) upon receipt by a protocol stack/device driver 
pair of an access request for one of the service 
programs, cloning the master control structure into 
a control structure (DCB) for that service pro- 
gram, the resulting service program control struc- 50 
ture including control information to associate the 
service program with the protocol stack/device 
driver pair receiving the access request; 

(d) creating a virtual circuit representing a communi- 
cation path between the external processing sys- 55 
tem, the protocol stack/device driver pair receiv- 
ing the access request, and the service program; 

(e) generating a control block (NCB) for each prede- 
termined block of actual data to be communicated 

to and from the service program, the control block 60 
including a data portion and information identify- 
ing the service program control structure for the 
service program; 
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(0 maintaining the service program control structure 
and the virtual circuit whUe actual data is commu- 
nicated between the service program, the protocol 
stack/device driver pair and the external process- 
ing system, wherein during such data communica- 
tion the data portion of each control block is trans- 
mitted over the virtual circuit; and 

(g) terminating the service program control structure 
and the virtual circuit upon completion of the data 
communication. 

2. The method as described in claim 1 wherein the 
operating system kernel includes first or second service 
interfaces between the service programs and the proto- 
col stacks. 

3. The method as described in claim 1 wherein the 
control structure includes a virtual circuit identification 
number. 

4. The method as described in claim 3 wherein the 
virtual circuit identification number identifies a virtual 
circuit control block including control information fa- 
cilitate data transfer to and from the device driver 
uniquely identified with the virtual circuit. 

5. The method as described in claim 4 further includ- 
ing the step of maintaining the virtual circuit control 
block while maintaining the data control block. 

6. The method as described in claim 1 wherein the 
application programs interface to the protocol stacks 
via calls to a first or a second service interface in the 
kernel. 

7. The method as described in claim 6, further includ- 
ing the step of: 

translating calls to the first service interface into calls 
to the second service interface such that an applica- 
tion program written for the first service interface 
is compatible with the second service interface 
without change to the kernel or the application 
program. 

8. The method as described in claim 3 wherein the 
first service interface is a Berkeley sockets style inter- 
face and the second service interface is an AT&T UNIX 
System V Streams transport layer interface (TLI). 

9. The method as described in claim 1 wherein the 
operating system kernel is UNIX System V. 

10. The method as described in claim 1 wherein the 
operating system kernel is Berkeley Sockets. 

11. The method as described in claim 1 wherein one 
of the protocol stacks implements the NETBIOS proto- 
col. 

12. The method as described in claim 11 wherein one 
of the protocol stacks implements the TCP/IP proto- 
col, 

13. The method as described in claim 11 wherein one 
of the protocol stacks implements the XNS protocol. 

14. The method as described in claim 1 wherein the 
protocol stacks implement the NETBIOS, TCP/IP and 
XNS protocols. 

15. The method as described in claim 1 wherein one 
of the device drivers interface to Ethernet: 

16. The method as described in claim 1 wherein one 
of the device drivers interfaces to a token passing ring. 

17. The method as described in claim 1 wherein one 
of the device drivers interfaces to a token passing bus. 

* * « • « 
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